Electronic form automation

ABSTRACT

Some embodiments may provide a method comprising receiving, from a remote machine, entity-identifying data and form identifying data, the form identifying data to identify a sequence of one or more electronic forms, the sequence including a target electronic form having a form element, determining an entity identifier, based on the entity-identifying data, accessing, from a data store, an entity attribute value based on the entity identifier, and transmitting, to the remote machine, form-filling instructions operable to cause a machine to automatically associate an entity attribute value with the form element.

RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.14/633,828, filed Feb. 27, 2015, which is a continuation of U.S. patentapplication Ser. No. 11/656,635, filed on Jan. 23, 2007, issued on Jun.30, 2015 as U.S. Pat. No. 9,069,745, which claims priority to U.S.Provisional Patent Application Ser. No. 60/885,180, filed on Jan. 16,2007, the benefit of priority of each of which is claimed hereby, andeach are incorporated herein by reference in their entirety.

TECHNICAL FIELD

The present application relates generally to the technical field ofmethods and systems to perform on-line ordering and payment processing.

BACKGROUND

In recent years, the Internet has made possible online commerceservices. Typically, a customer visits the web site of a merchant thathas set up a network-based commerce system. Once the customer hasselected some items to buy, the customer follows hyperlinks to a sectionof the web site where an order is placed, and a method of payment isentered, for the items. Typically, this process will require enteringdata in one or more pages. For example, a first web page may include anelectronic form where the customer enters his/her name, address, phonenumber, etc. Having entered these details, the customer presses a“submit” button and is directed to a next page to select a shippingmethod. Next, the customer may be directed to a page in which billinginformation and a billing address may be entered. This page may includean electronic form for entering credit card number, expiration date, andother billing information. Finally, the user is presented with a buttonwhich, when clicked upon, commits the transaction and sends theinformation to the merchant for billing and shipping.

Often, a customer will be in the habit of repeatedly purchasing itemsfrom a particular merchant or from several merchants. In this situation,the repeated entry of billing addresses, payment instrument information,and the like may be experienced by the customer as tedious.

Since the customer's shipping addresses, billing information, etc.typically do not change much over time, some network-based commercesystems offer the option to create an account for a customer for storingthese details, so that when a customer returns to make an additionalpurchase, the customer need only enter, for example, an email addressand password before clicking the transaction commit button to purchasean item.

This approach is limited, however, in that the customer must set up suchan account for each network-based commerce system through which thecustomer purchases goods or services, which with the rapid growth of adiversity of electronic commerce sites, may require setting up suchaccounts with a great many network-based commerce systems. In addition,some customers may hesitate to store their credit card numbers or othersensitive value-transfer facilitating information in numerousnetwork-based commerce systems, out of fear of fraudulent or erroneoususe by network-based commerce system personnel. Finally, if a customer'sdetails change (shipping address changes (for example, new shippingaddress due to a move to a new residence, reissued credit card with anew number, etc.), the customer will need to remember all their accountswith various web-based commerce systems, log into them, and updatehis/her details. If the customer is in the habit of utilizing a largenumber of network-based commerce systems, this wholesale updating may bea error-prone chore.

BRIEF DESCRIPTION OF THE DRAWINGS

Some embodiments are illustrated by way of example and not limitation inthe figures of the accompanying drawings in which:

FIG. 1 illustrates a checkout web page or other electronic form as itmay be presented within a graphical user interface on a remote machine,according to an example embodiment.

FIG. 2 is a block diagram of a system that may be used to carry outelectronic form automation, according to an example embodiment.

FIG. 3 illustrates an example of an electronic form, according to anexample embodiment.

FIG. 4 illustrates an overview of a number of data structures that maybe used by a network-based payment system, according to an exampleembodiment.

FIG. 5 illustrates an example of an entity attribute table, according toan example embodiment.

FIG. 6 illustrates an entities table and a form information table,according to example embodiments.

FIG. 7 illustrates a relationship between a form information table andan entity attribute table, according to an example embodiment.

FIG. 8 illustrates a sequence table, according to an example embodiment.

FIG. 9 is a flowchart of an overview process describing a number ofexample processes that may be carried out by a network-based paymentsystem, once the network-based payment system has received credential ofan entity, according to an example embodiment.

FIG. 10 and FIG. 11 include a flowchart of a process or carrying outautomatic filling of electronic forms and form sequences, according toan example embodiment.

FIG. 12 is a flowchart of a process for generating and transmitting formfilling instructions to a remote machine, according to an exampleembodiment.

FIG. 13 and FIG. 14 illustrate a user interface for electronic formautomation, according to an example embodiment.

FIG. 15 and FIG. 16 illustrate a flowchart of a process for anetwork-based payment system to learn entity attribute values, accordingto an example embodiment.

FIG. 17 is a flowchart of a process that may be used in associatingentity attribute values with entity identifiers and entity attributeidentifiers, according to an example embodiment.

FIG. 18 and FIG. 19 illustrate graphical user interfaces that may beused in learning entity attribute values in the context of electronicform automation, according to an example embodiment.

FIG. 20 illustrates an operation block that may be substituted foranother block within FIG. 16 to carry out electronic form sequencelearning, according to an example embodiment.

FIG. 21 illustrates a graphical user interface window that may be usedwithin a process for carrying out electronic form sequence learning,according to an example embodiment.

FIG. 22 is a flowchart of a process for processing entity attributevalues paired with form element identifying data, such as may be used bya network-based payment system in learning the sequence of electronicforms using entity attribute values, according to an example embodiment.

FIG. 23 shows a diagrammatic representation of machine in the exampleform of a computer system within which a set of instructions, forcausing the machine to perform any one or more of the methodologies,processes, or operations discussed herein, may be executed.

DETAILED DESCRIPTION

Example methods and systems to facilitate electronic form automation aredescribed. In the following description, for purposes of explanation,numerous specific details are set forth in order to provide a thoroughunderstanding of example embodiments. It will be evident, however, toone skilled in the art that the present invention may be practiced inother embodiments without these specific details.

Introduction

This specification includes descriptions of various example embodimentsof systems and methods for electronic form automation. In the course ofelectronic commerce or other activities, it may be necessary for usersto fill out forms using various user interface techniques. These formsmay be termed “electronic forms” in analogy to paper forms in that theymay include various form elements intended to permit a user to enterdata into their graphical user interface (GUI) representation. Theseelectronic forms may be presented or transmitted from web servers orother sources in a variety of formats including HyperText MarkupLanguage (HTML) or Extensible Markup Language (XML), or an electronicdocument in another markup language. Electronic forms may in someembodiments may include one or more form elements. These form elementsor descriptors (which may be rendered on a Graphical User Interface(GUI) or other user interface display as text entry boxes, check box,radio button, drop-down menus, selectable lists, and text entry fields,and the like). Upon receiving an electronic form from a server, amachine remote from the server may display the form within a web browseror other user interface application, receive user input corresponding tothe various form elements, and transmit the user input and associationsbetween the user input and the form elements to the server or anotherlocation or machine.

In the field of electronic commerce, electronic forms may be used. Forexample, a customer of a network-based commerce system (such as forexample an online merchant, a electronic commerce site, an online bank,an online brokerage, an online auction system, or the like), may, afterbrowsing through web pages or other electronic documents presentingdescriptions of goods or services for sale may select one or more ofthese goods or services for purchase. The customer's desire to completethe purchasing of the selected goods and services may be indicated byrequesting and receiving a web page or other electronic form by which acustomer may enter payment, shipping and other details to be transmittedto the network-based commerce system to complete the purchasetransaction. It will be appreciated that a variety of other onlineprocesses in which a user needs to supply various pieces of informationto complete a transaction or operation may also make use of electronicforms. A user may use a remote machine (e.g., not be directlyinteracting with the machine that served the form) to receive theelectronic document(s) including or comprising the form, and transmitthe values filled into the form and their associations with formelements.

An example embodiment of a checkout web page or other electronic form asit may be presented within a graphical user interface displayed on aremote machine to a customer is illustrated in FIG. 1 .

Referring to FIG. 1 , it will be appreciated that the user interfacewindow 102 entitled “Checkout” presents a graphical user interfacedepicting an electronic form. This electronic form, for the purposes ofexample, may be considered to have been served by the network-basedcommerce system “some_merchant.com” as evidenced by the Uniform ResourceLocator (URL) 104 serving to identify the electronic form presented inthe user interface window 102. The electronic form illustrated in FIG. 1includes various elements including a summary 106 of the transaction orpurchase that the electronic form is to enable a user to carry out aswell as graphical representations of a number of form elements includingthe name 110 of a customer or other entity wishing to purchasemerchandise, the address 114 and city, state and zip code 118 to whichthe merchandise being ordered is to be shipped. In addition, the exampleelectronic form presented by the graphical user interface illustrated inwindow 102 includes a field for the entry of a credit card number 122and a checkbox 126 to indicate whether the billing address for thecredit card number is the same as the shipping address. Finally, theelectronic form illustrated in window 102 includes a “Place Order”button 128.

When a customer or other user wishes to complete a purchase and placethe order for the purchased goods or services, the user may enter thename of the customer (or other entity on whose behalf the purchase isbeing made) into text fields 110, may enter other information into theother text fields 114, 118, 122 and may actuate the checkbox 126. Oncethis data has been entered, the user may click the “Place Order” button128, whereupon the web browser or other application running at theremote machine may associate the various data items entered by the userby the GUI with their corresponding electronic form elements andtransmit this data and these associations to the network-based commercesystem. Once this data is received by the network-based commerce systemmay process the order, request a credit via the credit card numberentered, serve another form to request credit card billing address, ortake other action.

Although a single-page electronic form illustrated in FIG. 1 , in someembodiments, network-based commerce systems or other electronic-formserving systems may present a sequence including multiple electronicforms that a user is to fill or navigate in order to carry out thepurchase of goods or services or other transactions. Not all of theelectronic documents in a sequence of electronic forms need bethemselves have fields for receiving input; in some embodiments one ormore electronic documents in a sequence may include submit-type buttonsthat permit navigation to a next electronic document or form withoutnecessarily submitting data entered in fields. Besides purchases, formserving may be used in various fields, such as for example registeringfor online services, online newsletter subscriptions or other services.For example, in some embodiments a network-based commerce system mayrequire a customer or other user to fill out the first electronic formincluding a shipping address, a second electronic form including billinginformation and a third electronic form in which the user is to entergift certificate numbers, discount coupon numbers or other information.In addition, some network-based commerce systems encourage a user toenter a username, membership number, or other data specific to aparticular online merchant. For a customer who uses a number ofdifferent network-based commerce systems and/or carries out a number oftransactions, the repeated entry of the name of the customer (or otherentity on whose behalf the customer is acting), addresses, credit cardnumbers, account numbers and other data may become burdensome. Thus insome embodiments, a network-based payment system or other trusted thirdparty may be entrusted to store various information about entities onwhose behalf electronic purchases and other online transactions may bemade. Such a third party may, at the request of users, provide scriptsor other machine-executable instructions, which may be generated asneeded and customized to the various forms that a customer may wish tohave automatically filled. Processes in which electronic forms arefilled (either partially or completely) automatically by a machine maybe termed “electronic form automation.”

While this specification describes embodiments in which various types ofdata is transmitted and received or otherwise communicated via a networksuch as, for example, the Internet, it will be appreciated that varioustransmission media such as wireless networking, wired and wirelesstelephony, text messaging, internet telephony and many other media maybe used to facilitate the various transmissions, receptions andacceptances described herein in regard to example systems forfacilitating the transfer of value. Further, it will be appreciated thatsome embodiments, communication among the various systems and modules bybe synchronous, asynchronous, or may be indirect, such as by one modulestoring a communication in a database or other storage device andindicating to another module its presence, without communicating itscontent.

For the purposes of this specification, a “module” includes anidentifiable portion of code or data or computational object to achievea particular function, operation, processing, or procedure.

Electronic form automation may have several example technical benefits.For example, using observation-based form field mapping techniquesincreases the accuracy of electronic form automation, and decreases theneed for a network-based payment system to custom program or manuallymap form fields.

Example Systems Used In Electronic Form Automation

FIG. 2 is a block diagram of a system 200 that includes various modulesand components that may be used to carry out electronic form automation,according to an example embodiment. System 200 includes a remote machine202 such as, for example, a home computer or other computer located atthe site of an entity or other customer. This remote machine 202 mayinclude a web browser or other communications applications that are ableto display GUI representations of electronic forms, receive user inputinto the electronic form representations, and transmit the input to theserver of the form, or to another machine. In addition, system 200 mayalso include a network-based commerce system 206 including a web server210. As mentioned above, some embodiments may be used in contexts otherthan commerce. In some embodiments, this web server 210 may be forserving electronic forms and receiving electronic form data as well asfor serving other types of electronic content (e.g., web pages withoutform elements, e-mail, etc). The remote machine 202 may be connected tothe network-based commerce system 206 via a network 204 such as, forexample, the Internet, intranets, wireless networks, telephone networks,etc. The system 200 also may include a network-based payment system 208.The network-based payment system 208 may include a number of modules andcomponents such as, for example, communication module 212, which may insome embodiments be a web server or other module capable ofcommunicating with the remote machine 202 via the network 204. Thenetwork-based payment system 208 may also include an identificationmodule 214 that may be used to validate logins and other requeststransmitted by the remote machine 202 purportedly on the behalf ofentities. The network-based payment system 208 may also include a datastore 218 for storing information about electronic forms, entities,electronic form sequences and other information. This data store 218 maybe connected to or accessed by other modules via a data access module216. For example, the data store 218 may be a relational database andthe data access module 216 may be a relational database accessapplication. The network-based payment system 208 may also include aninstruction generation module 220 which may be used to generateinstructions executable by the remote machine 202 to automatically fillin or read or record from electronic forms. The network-based paymentsystem 208 may include a learning module 221. This learning module maybe used to populate the data store 218 with data learned by recordingform value entry to learn the associations between form elements andentity attribute values, as will be described below.

Example Data Structures In Electronic Form Automation

FIG. 3 illustrates an example of an electronic form 302, according to anexample embodiment. The electronic form 302 illustrated in FIG. 3 iswritten in HyperText Markup Language (HTML). It will be appreciated thatin some embodiments Extensible Markup Language (XML) or some othermarkup language or format may be used for communicating and representingelectronic forms.

The electronic form 302 may include a number of features. For example,the electronic form 302 may include an action tag 308 to indicate theURL of the electronic document to be requested after the submission ofthe value to form element association data as well as an input formelement 310, a button element describing a “Place Order” button that auser may click once the electronic form elements, as represented in agraphical user interface, has been filled out. Finally the electronicform 302 may include other form elements such as, for example, a textbox indicated by the dashed box 304. Within, or otherwise associatedwith form elements, may be one or more pieces of form elementidentifying data such as, for example, the string (e.g., form elementidentifier) “FIRST_NAME” indicated by the bracket 306. When a userclicks a submit button on a user interface representing an electronicform, the value entered into an input field may be transmitted to theserver of the form or other destination in association with the formelement identifying data to indicate into which user interface elementthe value was entered.

FIG. 4 illustrates an overview of a number of data structures that maybe used by a network-based payment system 208, according to an exampleembodiment. These data structures may in some embodiments be stored indata store 218 and/or maintained by the network-based payment system208.

FIG. 4 includes a number of data structures including an entities table410, a network-based commerce system administrator table 422, an entityattribute table 402, a sequence table 440 and a form information table412. The entities table 410 may in some embodiments store informationabout customers or other entities on whose behalf data may be stored bythe network-based payment system 208. For example, an entities table mayinclude usernames, passwords and other account information. The entityattribute table 402 may include an entity identifier column 404, anentity attribute name column 406 and an entity attribute value column408. The entity identifier column may be a key into the entities table410. A row of the entity attribute table 402 may, in some embodiments,associate a value with an entity identifier and an attribute name. Thestructure of the entity attribute table 402 is described in more detailbelow with respect to FIG. 5 . In some embodiments, the entities table410 may be used by the identification module 214 to determine an entityidentifier based on credentials. Credentials may include a loginusername and password a user has previously registered with thenetwork-based payment system 208 to represent the user or other entity.

FIG. 4 includes a form information table 412. The form information table412 may include a number of columns including a network-based commercesystem (NBCS) identifier column 414, a form identifier column 416, aform element identifier column 418 and entity attribute identifiercolumn 420. The form information table 412 may be considered as amapping from a form identifier (such as, for example, a network-basedcommerce system URL) and a form element identifier to an entityattribute identifier. The content of the form information table 412 isdiscussed in more detail with respect to FIG. 6 , below.

FIG. 4 also includes a sequence table 440. This sequence table holdsdetails about sequences of one or more electronic forms. For example, insome network-based commerce systems as described above, a sequence ofone or more forms may be filled out to effect a purchase or othertransaction. The sequence table 440 may be used to store informationabout these multi-form input flows. The sequence table 440 and its useis described below in the discussion related to FIG. 8 .

Finally, FIG. 4 includes a network-based commerce system (NBCS)administrator table 422. This table may include an entity identifiercolumn 424, which may be a key into the entities table 410 and an NBCSidentifier column serving as a key into the form information table 412.This table may serve to map from the entity identifiers of known systemadministrators of the various NBCS's for which network-based paymentsystem 208 stores information to their administered NBCS's. Its use willbe described in further detail below.

FIG. 5 illustrates an example of an entity attribute table 502,according to an example embodiment. Entity attribute table 502 isillustrated as including information stored behalf of twoentities—entity identifiers E23653 and G10085. In the example of FIG. 5, the entity identifier E23653 corresponds to a person named DarrenCarbondiox, while entity identifier G10085 corresponds to a person namedAnna Caro. It will be appreciated that entities may be corporateentities and other non-natural persons. For each entity identifierillustrated in the entity attribute table 502, a number of name/valuepairs are stored. It will be appreciated that for consistency of dataprocessing, a network-based payment system 208 may find it desirable touse the same attribute name to designate the same attributes acrossvarious entities. For example, in the entity attribute table 502, itwill be appreciated that the same attribute names such as FIRST_NAME,LAST_NAME, ADDRESS, CITY, STATE, ZIP, CREDITCARD, etc. are used asentity attribute identifiers for both entities.

FIG. 6 illustrates an entities table 602 and a form information table606, according to example embodiments.

The entities table 602 illustrates examples of entity identifiers. Itwill be appreciated that these two entities described by the exampleentities table 602 correspond to the two entities for which attributevalues are stored in the example entity attribute value 502. Theentities table 602 may include a name of the entity as well as apassword and an email address (or other credentials). It will beappreciated that from the password and email address the identificationmodule 214 may be able to determine the corresponding entity identifier.

The form information table 606 illustrates an example of how a formidentifier such as, for example, a uniform resource location (URL) and aform element identifier or other form element identifying data may bemapped or otherwise associated with an entity attribute identifier. Insome embodiments, one function of a form information table, such as theform information table 606, may be to provide a standardization functionin which various form element identifiers used within the variouselectronic forms may map to the same entity attribute identifier. Thismay permit the network-based payment system 208 to generate scripts(e.g., via instruction generation module 220) to automatically fill inthe various electronic forms with entity attribute values regardless ofthe form element identifying convention used by a particular electronicform. The form information table 606 may include a number of columnsincluding the network-based commerce system (NBCS) identifier, the formidentifier, the form element identifier, and the entity attributeidentifier. In form information table 606, both an electronic formhaving a form identifier checkout.htm 608 and another form checkout2.htm610 are included. For example, checkout.htm 608 may be used by anetwork-based commerce system, some_merchant.com to requestidentification data from a purchaser while checkout2.htm 610 may be usedto request credit card information or other billing information from acustomer. This relation is depicted graphically in FIG. 7 .

FIG. 7 illustrates a relationship between a form information table 702and an entity attribute table 704, according to an example embodiment.

In the form information table 702, the form element identifier FN foundin some_merchant.com/checkout.htm electronic form is noted ascorresponding to the entity attribute identifier FIRST_NAME, while theform element identifier FIRST_N of www.mz_merchant.com/checkoutscr.htmalso corresponds to the same FIRST_NAME entity attribute identifier.Thus, it is possible for a network-based payment system to generatescripts to effect the automatic filling of various forms as long as therelationship between the ‘idiosyncratic’ form element identifiers of thevarious forms to the uniform entity attribute identifiers serving tomatch values to the entities for whom the network-based payment system208 stores data is known.

FIG. 8 illustrates a sequence table 802, according to an exampleembodiment. The sequence table 802 may be used by a network-basedpayment system 208 to store sequences of forms, such as for example whena network-based commerce system expects a user to fill out and/orotherwise traverse more than one electronic form to effect atransaction. The sequence table 802 may include a sequence column 804, asequence item column 806, a form column 808 and a next identifier column810. The sequence column 804 may be used to store identifying data toindicate a sequence to which a form belongs. The sequence item column806 may describe the order of forms within a sequence. For example, in asequence of forms maintained by some_merchant.com, the user during acheckout may be expected to fill in form checkout.html first and thenfill out the online electronic form checkout2.html next. The nextidentifier column 810 may indicate the name of a button element or otheraffordance to be clicked or otherwise actuated at the conclusion offilling out the corresponding form. For example, in the sequence table802, once the checkout.htm form has been filled out, the user may beexpected, via a browser, to click on a “Submit Form” button elementwhose identifier is NEXT_PAGE. It will be appreciated that sequences maybe stored in a number of different ways. The sequence table 802 may beused by the network-based payment system 208, in some embodiments, bythe instruction generation module 220 to generate scripts capable offilling in and traversing multiple forms within a sequence such as, forexample, a checkout flow.

Example Processes And User Interfaces Associated With Electronic FormAutomation

In some embodiments, a network-based commerce system or other system toserve electronic forms and/or electronic form sequences to a remotemachine may include a button element or other clickable element oraffordance on electronic documents or other element on electronicdocuments served to a remote machine. This element may, when a renderingof it is clicked within a user interface presented by a web browser,open a sub-window which the user of the remote machine is connected to anetwork-based payment system 208. This button may be labeled“Auto-Checkout” or “Form Automation” or similar label to distinguish itto a user. The server of the electronic document including such a buttonelement may also include form identifying data that may be received bythe network-based payment system 208 and thereby processed.

An example of such a button element is illustrated in Table 1.

TABLE 1 <a href=“javascript:void (window.open (‘http://www.xyz_pay.com/autoCheckout.htm’, ‘AC’, ‘height=200, width=450 ,top=20, left=20,scrollbars=no, location=1, resizable=1’) )”> <imgsrc=files/xyz_auto_checkout.gif border=0> </a>

As a result of the user clicking on the button element, a separatewindow (e.g., the sub-window) may be opened by a web browser or otherapplication on the user's machine. Once the user has connected to thenetwork-based payment system 208 (e.g., www.xyz_pay.com in Table 1)through this window, a web page may be presented within the sub-window(e.g., autoCheckout.htm of Table 1) to solicit entity credentials suchas for example a username and password.

In some embodiments, depending on the entity identification data enteredby the user and the configuration and identification of the form orother electronic document that included the button element, a number ofpossible actions may be carried out by the network-based payment system208.

FIG. 9 is a flowchart of an overview process 900 describing a number ofexample processes that may be carried out by a network-based paymentsystem 208, once the network-based payment system 208 has receivedcredential of an entity, according to an example embodiment.

At block 902, a user may click on an auto checkout request button orother button element (e.g., such as a GUI representation of that shownin Table 1) on an electronic document as rendered by a web browser orother communication application running on a user's remote machine. Inresponse, the user's web browser may open a connection to thenetwork-based payment system 208 (e.g., in a sub-window) via itscommunication module 212 by which the credentials of an entity, such asthe user or entity on whose behalf the user is logging in, may berequested. Once the user has entered these credentials at block 912, thenetwork-based payment system 208 may determine whether it has formmapping information about the site that served the electronic documentthat includes the button element. If so, at decision box 906, thenetwork-based payment system may determine whether it has enoughinformation about the entity whose credentials were presented to carryout an automatic form filling. If not, at block 908, the network-basedpayment system 208 may inform the user that not enough information isstored on the entity's behalf to facilitate automated form-filling, and,instead the network-based payment system 208 may serve a script to run(e.g., within the sub-window) to record the missing information as theuser works through the electronic form sequence presented in the mainwindow. On the other hand, if the network-based payment system does haveenough information about the entity at block 910, the network-basedpayment system 208 may provide form-filling instructions to enable theuser's machine to carry out an automatic form filling process on behalfof the entity via a script as will be described in further detail below.

Returning to decision box 904: if the network-based payment system 208does not have form mapping information about the site, the network-basedpayment system may determine whether the user is an administrator of thesite (such as a network-based commerce system) at decision box 912. Ifthe user is an administrator, such as by presenting the credentials ofan administrator of the network-based commerce system, then at block914, the user may make a sample transaction in order to train thenetwork-based payment system 208 to the site. This training process isdescribed in further detail below. In some embodiments, any user (whoneed not be an administrator of the network-based commerce system 206)may make a sample transaction by which the network-based payment system208 to the site; in such embodiments a transaction by any user on behalfof an entity for which the network-based payment system 208 hassufficient information may be used in this training process. It will beappreciated that when a network-based payment system doesn't have enoughinformation about the entity, the user need not, in some embodiments,input information into the electronic form served by the network-basedcommerce system 206, but may input their info into the sub-window.

FIG. 10 and FIG. 11 include a flowchart of process 1000 or carrying outautomatic filling of electronic forms and form sequences, according toan example embodiment.

FIG. 10 includes example processing that may be carried out by anetwork-based payment system 208, a network-based commerce system 206and a remote (e.g., user) machine 202. The process may begin at block1002, in which the network-based commerce system 206, for example, viaits web server 210, may transmit an electronic form (e.g., the firstelectronic form of a sequence) to a remote machine 202. Thistransmission may be in response to a user of the remote machine 202wishing to proceed with the purchase of goods or services or othertransaction. The electronic form transmitted in block 1002 need notinclude actual form data input elements, such as text fields, and mayinclude an auto checkout or similar form-filling script invocationbutton or buttons similar to the button element included in Table 1above. (An example of such a button element is illustrated at 1304 inFIG. 13 , described below)

At block 1004, after a remote machine 202 receives an electronic form orother electronic document from the network-based commerce system,including e.g. the form-filling script invocation button element, a userof the remote machine may click on or otherwise signal or actuate thebutton element or other similar affordance. In response to clicking onthis button (or other actuatable GUI) element, the web browser or othercommunication application running on the remote machine 202 may open asub-window on the display of the remote machine 202. This sub-window maybe populated with a GUI representation of an electronic form downloadedfrom the network-based payment system 208, to allow the user of theremote machine to transmit credentials to the network-based paymentsystem 208. (e.g., block 1008) These credentials may be transmitted tothe network-based payment system 208 and may be received by thecommunication module 212. In addition, form identifying data (e.g., theURL of the electronic form that includes the button element clicked) maybe transmitted in addition to the network-based payment system 208. Insome embodiments, an “http_referer” variable may be transmitted to thenetwork-based payment system 208 when the user clicks the button intable 1. The http_referer variable may be sent to a web server of asubsequent page whenever a user clicks on a link on a page. At block1010, the network-based payment system 208, in some embodiments theidentification module 214, may attempt to verify the credentialsreceived from the user. At decision box 1012, the credentials may beverified and if the credentials do not correspond or validate an entityon whose behalf the network-based payment system 208 is storinginformation, at block 1014 an error message may be transmitted to theremote machine to this effect. If the credentials are verified,processing may continue at block 1116 of FIG. 11 .

FIG. 11 is a continuation of the process illustrated in FIG. 10 . Atblock 1116 the network-based payment system 208 may transmit a GlobalUnique Identifier (GUID) or other identifier to the remote machine 202.This GUID may be stored by the network-based payment system 208 inassociation with the entity identifier (e.g., determined based onentity-specific data, such as for example the credentials) and the formidentifying data, such as for example a URL to identify a sequence ofone or more electronic forms. This GUID may be transmitted to the remotemachine later in the form automation process. For example, the GUID maybe sent by the network-based payment system 208 to be stored on theremote machine's 202 cookie. At block 1118, the remote machine mayreceive the GUID or other identifier which may in some embodiments bestored as a cookie.

At block 1118, the sub-window being displayed on the remote machine 202may be redirected to an electronic document served by the network-basedcommerce system 206 (in some embodiments by web server 210), which insome embodiments may be done to permit a script of form-fillinginstructions to have the same apparent domain name as the electronicform(s) that the form-filling instructions are to affect. An example ofsuch an electronic document in the form of an HTML page is illustratedin Table 2.

TABLE 2 <html> <head><title>XYZ Pay Automation</title></head> <body>Thank you Darren Carbondiox! Now entering your stored information...<script type=“text/javascript”src=“http://xyz_pay.com/fa_script.js”></script> </body></html>

It will be appreciated that the redirection of the sub-window toretrieve the script referencing HTML, such as illustrated in Table 3,may be necessary to allow a script served from a network-based paymentsystem 208, to be able to enter values or otherwise modify an electronicform illustrated in the original sub-window by virtue of sharing thesame domain name.

At block 1120, the remote machine 202 may render the script referencingHTML received from the network-based commerce system 206, such as theHTML or other electronic document illustrated in Table 2. At block 1120,during the rendering process in response to encountering the scriptinstruction, the remote machine 202 may request a script from thenetwork-based payment system 208 transmitting the GUID and othernecessary data. Table 3 illustrates an example of such a script, as onemay be implemented in JavaScript.

TABLE 3 opener.document.for5.FN.value =“Darren”;opener.document.for5.LN.value =“Carbondiox”;opener.document.for5.ADR.value =“123 Chicken Street”;opener.document.for5.C.value =“Denver”; opener.document.for5.ST.value=“WY”; opener.document.for5.PC.value =“20199”;opener.document.for5.ship_to_zip.value =“95131”;opener.document.for5.CC_NUM.value =“5552 1235 5678 9707”;opener.document.for5.B_A_SAME_BOX.selected = true;opener.document.for5.submit ( ); setTimeout (1000);

Once this script request, including the transmitting of GUID or otherdata, is received by the network-based payment system 208, such as bythe communication module 212, the network-based payment system 208 maydetermine the form identifying data and the entity identifier associatedwith the GUID. It will be appreciated that although the HTML page (e.g.such as shown in Table 3) may appear to be to retrieve a specific scriptand execute it during the rendering of the page, this script may in factbe generated according to the form or form sequence to be filled and theentity on whose behalf the filling is to be done.

The script may be generated by the instruction generation module 220.The script generated may include form filling instructions that areoperable to cause the remote machine 202 to automatically fill in thesequence of one or more electronic forms presented by the network-basedcommerce system 206.

The script generated at block 1124 may include a number of form fillinginstructions operable to cause the remote machine to automatically fillin a sequence of one or more electronic forms presented by thenetwork-based commerce system 206 or otherwise automatically associatean entity's attribute value with a form element in an electronic form.This script may be operable to automatically fill and submit a sequenceof forms, such as for example by interleaving instructions toautomatically fill in form elements with instructions to automaticallyactuate submit buttons or other form of submission affordances withinthe various electronic forms or other electronic documents comprisingthe sequence, such as to proceed from one electronic form to the next.The script may also serve to show progress updates within the sub-windowfor the users' benefit.

In order to generate a particular form filling instruction operable tofill a particular form element, the instruction generation module 220may access from the data store 218 an entity attribute valuecorresponding or otherwise associated with the entity identifier, theform filling instructions thus being operable to enter the entityattribute value so accessed into the electronic form.

This accessing process may in some embodiments include severaloperations. In some embodiments the instruction generation module 220,at the commencement of the generation of form filling instructionsoperable to associate an entity attribute value with a form element, mayselect form element identifying data corresponding to the form elementwithin a particular electronic form within a sequence of electronicforms for which instructions are to be generated.

The instruction generation module 220 may select an entity attributeidentifier from a data store 218 where the entity attribute identifieris associated with a target form identifying data (e.g., where a targetform may be an electronic form into which, or from which, data is to beentered or recorded) and a form element identifying data. For example,suppose that in referring to FIG. 6 instructions were being generated tofill in a form element whose form element identifying data is CC_NUM 612within the electronic form checkout2.html served by some_merchant.com610. In that example, the entity attribute identifier selected may bethe entity attribute identifier CREDITCARD 614. Finally, the instructiongeneration module 220 may select the entity attribute value from thedata store that is associated with the entity attribute identifier andthe entity identifier. For example, to continue the example above, theinstruction generation module having ascertained (e.g., from the GUID)the entity identifier, for example E23653, within the entity attributetable 502 and the entity attribute identifier CREDITCARD 614 from theform information table 606, may select the attribute value5552123556789707 504 from the entity attribute table 502. Thus, it maybe this value that the instruction generation module 220 may generateinstructions to automatically enter into the checkout2.html 610 form inthe form element corresponding to CC_NUM 612, within a script (such asin Table 3) generated on behalf of the entity identified by E23653.

In generating the script, a form information table, such as that shownat 606 may be used or other mechanism invoked, such as for assemblingscripts for filling multiple forms.

At block 1126, the script may be transmitted to the remote machine 202whereupon at block 1128 the script may be executed within the remotemachine to automatically fill in the sequence of one or more electronicforms in the main window and a submission of the form entries in themain window to the network-based commerce system 206. Finally at block1130, the form entries may be received by the network-based commercesystem 206 and the network-based commerce system 206 or other system mayprocess the checkout or other transaction.

In some embodiments, an electronic form served by a network-basedcommerce system 206 may be via HTTPS (or other secure protocol). Inthese embodiments, a non-secure page cannot talk to, fill forms, or readforms on a secure page. In those embodiments, a script generated by aninstruction generation module 220 may include instructions to reload thepage on which it resides as a secure page prior to executing. Forexample, the script illustrated in Table 3 may include a line:“window.location.href=‘https://www.some_merchant.com/checkout_secure.htm?page=2’;”or the like. In these embodiments, the “checkout_secure.htm” page wouldbe as illustrated in Table 2.

FIG. 12 is a flowchart of a process 1200 for generating and transmittingform filling instructions to a remote machine, according to an exampleembodiment.

At block 1202, the network-based payment system 208 may receiveentity-identifying data, such as for example a cookie including a GUIDfrom which an entity identifier may be determined or a user name,password, or other credential, and form identifying data. This formidentifying data may identity a sequence of one or more electronic formssuch as for example by identifying the Uniform Resource Locator (URL) ofthe initial form or document in the sequence. Within the sequence of oneor more electronic forms, the sequence may include one or more targetelectronic forms having one or more form elements. In some embodiments,the entity-identifying data and form identifying data may be received bya communication module 212.

At block 1204, an entity identifier may be determined based on theentity-identifying data. This entity identifier may be to identify theentity on whose behalf the entity-identifying data was received.Beginning at block 1206, a series of operations may be carried out toenable an instruction generation module to generate instructions toautomatically fill in the various form elements within the varioustarget electronic forms that comprise the sequence of forms. For eachtarget electronic form, form element identifying data corresponding to aform element within the target electronic form may be selected. At block1208, an entity attribute identifier may be selected. The selection ofthe entity attribute identifier may be based on the target formidentifying data (such as for example the URL of a particular electronicform within a sequence of electronic forms) and form element identifyingdata. Also, in block 1208, once an entity attribute identifier has beenselected, an entity attribute value may be selected based on the entityattribute identifier and the entity identifier. At block 1210, formfilling instructions operable to cause a machine to automaticallyassociate the entity attribute with the form element may be created. Atdecision block 1212, a determination may be made whether more formelements need to be processed within the sequence of electronic formsfor which form filling instructions are being generated. If there aremore form elements to be processed within a current target electronicform, processing may continue at block 1206. If there are no more formelements to process within a particular target electronic form within asequence, processing may continue with the next target electronic formin the sequence with the collection of all form filling instructions.The form filling instructions may further include instructions to submitthe target electronic form in preparation for automatically filling outthe next electronic form in the sequence.

On the other hand, if at decision block 1212 there are no more formelements to be processed in the sequence of electronic forms, thenprocessing may continue at block 1215 with the transmission of all theform filling instructions to the remote machine, such as for example allthe form filling instructions to fill out all the form elements withinthe various electronic forms that comprise the sequence. As discussedabove, these form filling instructions may be encapsulated within ascript served to a remote machine in response to a request from theremote machine.

It will be appreciated that in some embodiments, a web browser toolbaror other plug in may be used to carry out the operations illustrated inFIGS. 10 through 13 . For example, a user of a remote machine 202 maydownload a toolbar or other “plug-in” application (e.g., from anetwork-based payment system 208) when a user wishes to be able torequest automatic filling of electronic forms. Once such a toolbar orplug-in has been integrated into a communication application on theremote machine 202, a user may enter an entity's credentials into thetoolbar whereupon the toolbar may transmit the credentials along with anidentification of the URL to the initial electronic form or otherelectronic document in a sequence to the network-based payment system208. In response, the network-based payment system may use a processanalogous to that illustrated in FIG. 12 to generate and transmit ascript back to the toolbar or plug-in for execution by the toolbar orother plug in, or within the web browser, to automatically fill in thesequence of the one or more electronic forms.

It will be appreciated that not every electronic document within anelectronic form sequence need have form elements that may be filled inby a user. For example, a sequence of electronic forms may includeseveral electronic documents that may be considered electronic forms,but merely permit a user to click a “next page” type button to proceedto the next electronic document or form in the sequence.

FIG. 13 and FIG. 14 illustrate a user interface for electronic formautomation, according to an example embodiment.

In FIG. 13 , a user interface 1302 in a first or main window, such asfor example a window presented on a remote machine by a web browserapplication (e.g., a web browser window), is illustrated. The userinterface 1302 may for example be presented in response to a userretrieving an electronic form from a secure web server, such as forexample a web server 210 in a network-based commerce system 206. In theexample illustrated in FIG. 13 , an electronic form whose URL isillustrated in the address field 1303, has been requested and receivedby the remote machine. The electronic form has thus been rendered withinthe user interface 1302. The electronic form includes form elements forthe entry of a name, address, city, state, zip code, credit card numberand a checkbox indicating whether the billing address is the same as theaddress the user has entered in the form. In addition to the variousfields form elements, the electronic form illustrated in the userinterface 1302 may in some embodiments be referred to as a main windowand includes two button elements: An “Auto Checkout” button 1304 and a“Place Order” button 1305. In the absence of electronic form automation,the user wishing to place the order illustrated in the user interface1302 may enter an entity name, address and other information and thenclick on the “Place Order” button 1305. On the other hand, thenetwork-based commerce system 206 or other electronic form server mayprovide the “Auto checkout” button 1304 (e.g., via a form element asillustrated in Table 1). The “Auto checkout” button 1304 when clickedmay cause the web browser application running on the remote machine 202to open a second window 1306. The second window, by contrast with themain window displaying user interface 1302, may direct the user to anetwork-based payment system which a second electronic form having a URLindicated in address box 1308 may be downloaded.

As illustrated in FIG. 13 , the second window 1306 may includeelectronic form elements 1310 and 1313 to allow the entry of credentialsfor an entity such as for example an email address and/or password. Oncethese credentials have been entered, the user may click a continuebutton 1314, such as by positioning a mouse pointer 1316 onto thecontinue button and click a mouse attached to the remote machine.

In FIG. 14 , the user interfaces 1302 and 1306 are illustrated in astate after the user has clicked the continue button 1314 of FIG. 13 ,according to an example embodiment. It will be appreciated that thesecond window 1306 has been redirected to the web page on thenetwork-based commerce system's site as evidenced by the URL in theaddress box 1416. As illustrated in user interface shown in the secondwindow 1306, a confirmation message has been provided to the user and inthe rendering of the page (e.g., such as for example in Table 2)indicated by the URL 1416 that includes the acknowledgement message. Ascript (e.g., such as for example as illustrated in Table 3) provided bythe network-based payment system 208 may have been downloaded in theprocess of rendering the page illustrated in the second window 1306, thescript having automatically filled in the various pieces of informationin the user interface 1302 into the form element GUIs. Requesting thescript from the network-based payment system, the remote machine 202 mayin some embodiments have presented a global unique identifier (GUID),such as stored in a cookie on the remote machine 202, as provided by thenetwork-based payment system 208 in response to successful verificationof the credentials (entered in fields 1310 and 1313 in FIG. 13 ). Intransmitting the credentials to the network-based payment system 208, anindication of the URL or other form identifying data from the mainwindow containing user interface 1302 may have been transmitted.

Once the entity attribute values have been automatically entered intothe user interface, the script may further provide for the automaticinvocation of the “Place Order” button 1305.

Example Methods And Systems For Entity Attribute Value Learning

In portions of the specification above, operations, systems and userinterfaces are presented in which electronic form automation may becarried out using the transmission of various form filling instructionsfrom a network-based payment system to a remote machine in which a webbrowser or other form display and form data collection application maybe executing. It will be appreciated that in order to carry out thegeneration of form filling instructions to fill in a sequence of one ormore forms, it may in some embodiments be a precondition to the formfilling instruction generation that entity attribute values appropriateto the entity on whose behalf the one or more electronic forms withinthe sequence are being filled as well as the mapping or relationshipbetween the entity attribute values and the form elements for which formfilling instructions are to be generated, be available to thenetwork-based payment system 206 and in some embodiments to theinstruction generation module 220 from a data store 218.

In some embodiments, however, while a network-based payment system 208may have information describing the relationship between form elementswithin a sequence of one or more electronic forms and entity attributeidentifiers for a particular entity, the network-based payment systemmight not have corresponding entity attribute values to those entityattribute identifiers for a particular entity for whom the network-basedpayment system 208 maintains personal or demographic information. Underthese circumstances, it may be possible in some embodiments for thenetwork-based payment system 208 to learn the values of various entityattribute values for a particular entity by receiving those values froma remote machine 202, the remote machine 202 having recorded thosevalues as entered within one or more electronic forms by the entity orby a user entering them on behalf of the entity.

In overview, this process may be carried out by the provision of abutton element within an electronic document served by the network-basedcommerce system 206 website or other form server. This electronicdocument may be rendered in a first browser window. Upon clicking thisbutton element, a second window may be opened by the web browserapplication, in some embodiments running on the remote machine whereinthe second window includes in its rendering the execution of a script toobserve the entry of values into and/or navigation among one or moreelectronic forms illustrated within a first browser window. Once acheckout flow or other form entry process has been completed by a user,the user may indicate the process is completed whereupon the credentialsof the entity on whose behalf the user was entering data into the formelements may be requested. These credentials along with the recordedvalues may be transmitted to a network-based payment system and if thecredentials entered by the user match those associated with the entityon whose behalf the user is purportedly acting, the values may becomeassociated with the entity.

It will be appreciated that the entry of the credentials may precede orfollow the recording of the values by the user into the electronic formor forms provided by the network-based commerce system 206 or other formserver. In some embodiments, when the credentials are to the entered atthe beginning of the process, the network-based payment system 208 may,based on the credentials and the form identifying data that may identifya sequence of forms, determine whether sufficient data is stored in thenetwork-based payment system for the entity for whom credentials wereentered to carry out automated form filling as described in thepreceding sections or whether the network-based payment system does nothave sufficient information, in which case the user may be invited toenter the values into the forms as described below.

FIG. 15 and FIG. 16 illustrate a flowchart of a process 1500 for anetwork-based payment system to learn entity attribute values, accordingto an example embodiment.

In the flowchart illustrating process 1500, various entity attributevalues are illustrated as being recorded via a script or otherinstructions running on a remote machine 202. These entity attributevalues may be later transmitted to a network-based payment system 206 inconjunction with credentials associated with that entity that arereceived after the recording. It will be appreciated that in some otherembodiments the credentials may be received at the remote machine and/ortransmitted to the network-based payment system 206 prior to recordingof values at the remote machine 202.

At block 1502, a network-based commerce system 206 or other form servingsystem, may transmit an electronic form to a remote machine. Thiselectronic form may be a single electronic form or may be one electronicform out of a sequence of one or more electronic forms. At block 1504, aremote machine 202 may open a second (e.g. sub-window) in response tothe user interacting with some GUI representation of an element in theelectronic form. For example, in some embodiments, this sub-window maybe opened in response to the clicking by a user on a button element ingraphical representation of the electronic form or other electronicdocument. Such a button element may be similar to the one illustrated inTable 1 and may be represented by a GUI such as button 1804 of FIG. 18 .At block 1506, the prompt message to the user to enter entity attributevalues into the graphical user interface of the electronic form may bepresented, such as in the sub-window. This prompt may be part of ascript served from the network-based commerce system 206 and the scriptmay also include machine-readable instructions for recording the entriesof the values into the one or more electronic forms.

An example of pseudocode for such a script is illustrated in Table 4, toillustrate the recording of a value from the ‘FN’ form element.

TABLE 4 document.opener.for5.FN.onchange=“window [ ‘AC’ ] .document.recorder.FN.value=this.value;’ document.write(“<formname=recorder action=http://xyz_pay.com method=post>”);document.write(“<input type=hidden name=FN value=‘’>”);document.write(“<input type-submit value=‘Click here to submit yourinformation to xyz_pay’>”); document.write(“</form>”);

At block 1508, the user of the remote machine may enter values into thegraphical user interface of the electronic form or sequence ofelectronic forms. The script running in the sub-window may, in responseto the user entry of the values, store these values in the remotemachine 202. At block 1510 the user may click an e.g. “Done” or“Complete” button in the sub-window to indicate the completion of thevalue entry recording process. It will appreciated that when theelectronic form or electronic form sequence is being shown in a webbrowser window as having been served by a particular web domain, thescript running in the second browser window or sub-window may accessand/or record user entries in the first window when the electronicdocument (including the script) is served from the same domain as theelectronic form.

Processing may then continue at block 1612 of FIG. 16 . At block 1612the network-based payment system 208 may receive a request for acredential script. This request may be transmitted from the remotemachine as actuated by the user clicking the “Done” button. This requestmay be carried out by arranging for the “Done” button to also redirectthe sub-window to the URL served by the network-based payment system206. At block 1614, the remote machine 202 may present a credentialreceiving form received from the network-based payment system 208 andthereby receive credentials from the user. These credentials receivedmay for example be a login name or email address and passwordcorresponding to the entity on whose behalf the user is recordingattribute values as entered in the electronic form or forms. In responseto the entry of the credentials (continuing at block 1614) thecredentials may be transmitted to the network-based payment system 208.At block 1616 the network-based payment system 208 may verify thecredentials to determine whether they correspond to an entity that thenetwork-based payment system 208 recognizes and/or maintains informationon the entity's behalf. At block 1618 the network-based payment systemmay verify the authenticity of the credentials. If the credentials arenot verified, an error message may be transmitted to the remote machine202 at 1620. In some embodiments, the sub-window need not include adone/submit button. For example, the sub-window may wait for the user toclick submit on the final electronic document of the sequence and thenautomatically self-submit to the network-based payment system 208 (e.g.xyz_pay.com in the examples here.)

On the other hand, if the network-based payment system 208 verifies thecredentials at 1618, then at block 1620 the network-based payment system208 may request entity attribute data and the corresponding form elementdata as well as form identifying data from the remote machine 202. Itwill be appreciated that in the recording and storage of entityattribute values at 1508, the remote machine 202 may store therelationship between the values entered and the form elements into whichthe values were entered by the user as well as indications of the formidentifying data to identify the first electronic form and anyadditional electronic forms in the sequence. It is this information themapping between values entered by the user and the electronic forms towhich that data pertained that may provide the raw data to associate thevalues entered with the entity on whose behalf the values were entered.

At block 1622, the stored data mentioned above may be retrieved by theremote machine 202 and transmitted to the network-based payment systemand at block 1624 the network-based payment system may receive the dataand store it in the database according to the form element identifyingdata to create an association between the entity attribute data and theentity attribute identifiers.

FIG. 17 is a flowchart of a process 1700 that may be used in associatingentity attribute values with entity identifiers and entity attributeidentifiers, according to an example embodiment.

At block 1702, entity-identifying data may be received via acommunication module 212. The entity-identifying data may include a username, password, cookie, or other combination of data to identify anentity.

At block 1704, an entity identifier may be determined based on theentity-identifying data, for example given a password and an emailaddress, an entity identifier may be retrieved from an entity's table,such as for example entities table 602 in FIG. 6 . This may be carriedout by an identification module 214 in some embodiments.

At block 1706, target form identifying data to identify targetelectronic form having a form element may be received. In addition, formelement identifying data to identify the form element may be received.For example, a URL or other data to identify a target electronic formmay be received as well as form element identifying data to identify aform element within the target form. The form element identifying datamay include, for example, a string such as that indicated at 306 of FIG.3 . At block 1710, an entity attribute value may be received. It will beappreciated that in this point in the process, the entity to which thisentity attribute value corresponds may not yet be determined as in someembodiments the processing of block 1704 may occur later than theprocessing of block 1712. The operations of blocks 1706 and 1710 may becarried out by the communication module 212.

At block 1712, an entity attribute identifier may be selected. Thisselection may be carried out by the learning module 221. This entityattribute identifier may be associated with the target form identifyingdata and the form element identifying data. For example, referring toform information table 606 of FIG. 6 , if the form identifying dataincluded the form identifier, some_merchant.com/checkout.html and theform element identifying data included the form element “ADR”, theentity attribute identifier selected in block 1712 may be the entityattribute identifier “ADDRESS”.

Finally, at block 1714, an association may be stored (e.g., by thelearning module 221), such as, for example, association data thatassociates the entity attribute value with the entity attributeidentifier and the entity identifier. For example, if the entityattribute identifier “ADDRESS” was selected at 1712, the entityidentifier “E23653” is then determined at block 1704 and the value “123Chicken Street” then received at block 1710, the processing at block1714 may serve to store this association in an entity attribute table,for example entity attribute table 502 in row 504.

At block 1716, a determination may be made (e.g., via a learning module221) as to whether more (value/form element) pairs are to be processed,such as for example, associations between values and form identifyingdata and form element identifying data. If not, the process 1700 may becomplete. On the other hand, if more value and form element pairs are tobe processed, processing may continue at block 1706. Such processing maycontinue for each of the electronic forms in the sequence for which userentries were received.

FIG. 18 and FIG. 19 illustrate graphical user interfaces that may beused in learning entity attribute values in the context of electronicform automation, according to an example embodiment.

FIG. 18 illustrates an example graphical user interface 1802, such asmay be displayed by a web browser application on a remote machine 202 inresponse to a user requesting an electronic form, such as for example,the checkout.htm form represented in the user interface 1802.

Assume for the purposes of example that the particular customer has madea purchase from the “some_merchant.com” network-based commerce system.To simplify the example, assume that a sequence of electronic formsincluding only one form is used to checkout and complete thetransaction. In filling out the electronic form represented by graphicaluser interface 1802, an entity such as customer Darren Carbondiox mayenter various pieces of information and then complete the transaction bypressing a “Place Order” button 1803. On the other hand, suppose thatthe customer has not yet stored his or her name and address or creditcard number with the network-based payment system 208, but wishes forthe network-based payment system 208 to retain this information forfuture use, such as from checking out or making other transactions fromother network-based commerce systems or other form serving systems inthe future. To facilitate this, the form or other electronic documentserved by the network-based commerce system 206 and represented bygraphical user interface 1802 may include a “Watch Checkout” (or thelike) button element, represented by clickable button 1804. Whenclicked, this “Watch Checkout” button may open a second sub-window suchas the record sub-window 1806. In order to record the form valuesentered into the user interface 1802, this sub-window 1806 may permitthe requesting of an electronic document including or referencing arecording script. To facilitate the observation of value entry in theuser interface 1802, this electronic document, within the browsersecurity model, may be from the same domain as the domain that servedthe electronic form or other electronic document represented by userinterface 1802. This domain name correspondence may be noted byreference to address textbox 1816, within the sub-window 1806.

In rendering the electronic document in the sub-window 1806, a welcomemessage to encourage the user to enter their information into the userinterface 1802 may be presented. In some embodiments, the storage ofvarious entity attribute values by a third party (e.g., a network-basedpayment system 208) in association with an entity may be termed an“electronic wallet” or “wallet account.”

In response to this text, in the example illustrated in FIG. 18 , a useris entering data in the electronic form displayed in the user interface1802 on behalf of Darren Carbondiox and is just about to enter the stateinformation as illustrated by the position of the cursor 1807. Once theuser had entered this information and information on any otherelectronic forms involved in the checkout flow or other form sequence, auser may click the “Done” button 1808 in the sub-window 1806. In someembodiments, the sub-window 1806 may include a text such as “Click tosubmit your information to xyz_pay.”, referring to the examplenetwork-based payment system 208 illustrated in the tables and figures.

Once the customer has clicked on the “Done” button 1808, the variousvalues and other information recorded by the script may be stored withinthe remote machine 202, such as for example by being stored as cookiesor other storage artifacts. Once the user has clicked the “Done” button1808, the sub-window 1806 may be redirected to the network-based paymentsystem 208 to receive a form permitting the entry of credentials for theentity for whom the values were being recorded as indicated by thenetwork-based payment system 208 served page credent.htm URL,illustrated in the address field 1920. The sub-window 1806 may transmitthe entity attribute values to the network-based payment system 208 forstorage. The network-based payment system 208 may solicit authenticationor credentials to correctly and securely associate the entity attributevalues with the right entity.

In response to receiving the credential requesting form from thenetwork-based payment system 206 and rendering it in the sub-window1806, the user may enter the credentials, such as for example an emailaddress, username, user ID, password, etc. for example, into the textfields 1922 and 1924. Once this is done, the user may click the“Continue” button 1926, such as by positioning cursor 1928 over thisbutton and pressing an input device button.

It will be appreciated that, in addition to using a web interface, it isalso possible in some embodiments to provide interfaces through a mobileterminal, a cell phone, interne telephony or other media.

Systems And Processes For Learning Associations Between Entity AttributeIdentifiers And Form Element Identifiers Or Form Element IdentifyingData

In the sections above in which FIG. 13 through FIG. 19 are described, itmay be that a network-based payment system has information about asequence of electronic documents, such as a sequence of electronicforms, as well as form information, such as for example illustrated inform information table 606, which may be used to map from form elementsidentifying data to entity attribute identifiers. In this way, anetwork-based payment system 208 may receive entity attribute values,and by cross-referencing an entity identifier with the values entered inthe various form elements with the form element identifying data toentity attribute identifiers, the network-based payment system 208 maylearn entity attribute identifier to entity attribute value associationsfor a particular entity.

In some embodiments, a network-based payment system 208 may not yet haveinformation about a particular sequence of one or more electronicdocuments, such as electronic forms, or have mappings from electronicforms and form element identifying data to entity attribute identifiers,of the type illustrated in the example form information table 606.

In order to learn the structure of a sequence of one or more electronicforms, a network-based payment system 208 may store information about anentity including all of the entity attribute values to be entered intothe sequence of forms. For example, suppose that a network-basedcommerce system 206 includes a product checkout flow including threeelectronic forms. Suppose further, that a particular entity, such as forexample a system administrator of the network-based commerce system 206,has all of the entity attribute identifier/value pairs stored by thenetwork-based payment system 208 that may be necessary to carry out asample checkout flow.

Then if the network-based payment system receives (in an authenticatedmessage from e.g. a remote machine 202 authenticated by credentials ofthe network-based commerce system 206 and its administrator) mappingsbetween form element identifying data and values stored by thenetwork-based payment system 208 for that administrator, thenetwork-based payment system 208 may be able to infer the mappings fromform element identifying data, such as form element identifiers andentity attribute identifiers such as illustrated in the form informationtable 606. In addition, the network-based payment system 208 may beprovided with other data that may be used to learn the sequence, such asfor example a sequence of button element activations that may be used togenerate script or other set of instructions or automated filling andsubmission of the various electronic forms included in the sequence.

As in the process for the network-based payment system to learn entityattribute values illustrated in FIG. 15 and FIG. 16 , the process tolearn form information about a sequence of one or more electronic forms,based on the entry of values corresponding to a particular entity, maybe carried out by having a user first enter credentials for the entity,such as the system administrator of a network-based commerce system intoan electronic form served by the network-based payment system 208 andthen be redirected to a URL of an electronic document served by thenetwork-based commerce system along with the provision of a GUID, suchas by cookie, whereupon the user may be prompted to enter values tocarry out a sample form entry flow within a sequence of forms served bythe network-based commerce system 206 or other form server. In someother embodiments, a form entry value recording script may be served bythe network-based commerce system 206. The script may provideinstructions to store the pairings of form values and form elementidentifying data on the remote machine 202, such as in the form ofcookies, that may be retrievable by a web page script served later fromthe network-based payment system 208 in conjunction with the entry ofentity's credentials.

Table 5, below, illustrates pseudocode that indicates how pairings ofform element identifying data and form values may be stored. Thepseudocode of Table 5 includes a clickable button element that a user ona remote machine 202 may click or otherwise actuate after submitting aform served from a network-based commerce system 206. Once a user hasclicked the button in the sub-window (e.g. sub-window 2108), the remotemachine 202 may transmit the form element identifying data/form valuepairs to the network-based payment system 208, where the for values maythen be normalized and mapped.

TABLE 5 // simplified version of a field/value learning tool // Thiscode is part of the javascript include // attach onsubmit to each formon the page for (i=0; i<opener.document.forms.length; i++)  opener.document.forms [i] . onsubmit=“window [ ‘AC’ ] .grabFormEntries(this);” function grabFormEntries(frm) {  for (i=0; i<this.elements.length; i++) {  document.recorder.field_nms.value=document.recorder.  field_nms.value+ ‘,’ this.elements [i].name  document.recorder.vals.value=document.recorder.vals. value+ ‘,’+this.elements [i].value  }  document.write(“<form name=recorderaction=http://xyz_pay.com method=post>”);  document.write(“<inputtype=hidden name=field_nms value=‘’>”);  document.write(“<inputtype=hidden name=vals value=‘’>”);  document.write(“<input type=submitvalue=‘Click here to submit your information to xyz_pay’>”); document.write(“</form>”);

At the network-based payment system 208, the server-side pseudocodeillustrated in Table 6 may be run, such as for example by the learningmodule 221.

TABLE 6 for each entityAttribute  for i=1 to listLength (vals)   // loopthrough all values to see if any value  entered by the user equates to aknown attribute  mapping   if vals (i) = entityAttribute.value then formElement = field_nms (i)  loop loop

In this second embodiment, the process for receiving and processingentity data may be similar to that illustrated in FIG. 15 and FIG. 16but may differ insofar as block 1624 may be replaced with block 2020 ofFIG. 20 , in an example embodiment. In block 2020, data including formelement identifying data and values, as well as data describing therecorded form sequence flow, such as for example sequences of buttonelement actuations, may be received. The entity attribute values may becorrelated with the values received as paired with the form elementidentifying data to create associations between the form elementidentifying data and entity attribute identifiers.

Sequence related information, such as for example the button elementsactuated to proceed from one electronic form to the next within thesequence as clicked by the user during the recording phase, may be usedin constructing a sequence table 802 of FIG. 8 . In addition, in someembodiments, the network-based commerce system administrator table 422may be used to indicate which entity identifier, such as for example incolumn 424, are eligible to have their attribute value data used inlearning form information and form sequence flows within forminformation table 412 by the use of the network-based commerce systemidentifier column 426 serving as a key to the network-based commercesystem identifier column 414 in some embodiments.

FIG. 21 illustrates an example of a user interface sub-window 2106 thatmay be used in recording a user's interactions with a sequence ofelectronic forms for learning a mapping between form element identifyingdata and entity attribute identifiers, according to an exampleembodiment.

In the user interface window 2106 (which may be a sub-window running ona remote machine 202), a user may retrieve a script-referencingelectronic document from a network-based commerce system 206 or otherform provider having the URL illustrated in the address box 2116. Thiselectronic document may include a “Done” button 2108 as well as amessage to the user to indicate that the user is to enter various pieceof information associated with an entity into a sequence of one or moreelectronic forms in the main or first window, such as for example firstwindow housing user interface 1802. The sub-window 2106 may thus beconsidered analogous to the sub-window 1806 of FIG. 18 .

This script-referencing electronic document may include or reference ascript capable of recording the various pairings between user-enteredvalues and form element identifying data and in some embodiments thesequence of button element actuations used to traverse or navigate theform element sequence or the electronic document sequence that includesone or more electronic forms.

FIG. 22 is a flowchart of a process 2200 for processing entity attributevalues paired with form element identifying data, such as may be used bya network-based payment system in learning the sequence of electronicforms using entity attribute values, according to an example embodiment.

At block 2202 a network-based payment system 208, or other systemmaintaining data store 218, including for example data structures suchas illustrated in FIG. 4 , may receive entity-identifying data, such asfor example the username and password of an entity that may serve toidentify an entity for which entity attribute values and theirassociated entity attribute identifiers are to be used in the learningprocess. At block 2204, an entity identifier may be determined, based onthe entity-identifying data. The processing in block 2202 and 2204 maybe carried out by a communication module 212 and identification module214, respectively. At block 2206, target form identifying data may bereceived to identify a target electronic form, such as for example oneelectronic form within a sequence of one or more electronic forms, inwhich the target electronic form has a form element. This form elementmay in some embodiments include a text entry box, a checkbox descriptor,a text entry box descriptor or radio button descriptor, a drop down menudescriptor, a selectable list descriptor or a text entry fielddescriptor. Form element identifying data to identify the form elementmay also be received at block 2208.

At block 2210 an entity attribute value may be received. This entityattribute value may be transmitted by a remote machine 202 inassociation with the form element identifying data which may serve toidentify the form element into which a user entered the entity attributevalue. At block 2212 an entity attribute identifier may be selected by alearning module 221 from an association among the entity attributevalue, the entity attribute identifier and the entity identifier. Forexample, referring to FIG. 5 , suppose that the entity identifierdetermined at block 2204 is determined to be the identity identifier“E23653” and the entity attribute value received at block 2210 is thestring “123 Chicken Street”. In this example, the attribute identifierselected at block 2212 may be the “ADDRESS” entity attribute identifierfrom the association indicated at 504. At block 2214 an associationamong the entity attribute identifier, the target form identifying dataand the form element identifying data may be stored, such as for exampleby the learning module 221. Continuing the example, suppose that thetarget form identifying data is a form identifier“www.some_merchant.com/checkout.htm” and the entity attribute identifierselected at block 2212 is the “ADDRESS” string and the form elementidentifying data is the string “ADR”. In response, the network-basedpayment system 208 may store an association, such as for example theassociation 616 into the data structure such as form information table606 and thus associate an entity attribute identifier with a formidentifier and a form element identifier.

At decision box 2216, a decision may be made (e.g. via the learningmodule 221) as to whether more value to form element pairs need to beprocessed. In some embodiments, all form element or form elementidentifying data to value pairs within a particular electronic form maybe processed before processing those pairs entered into another formsuch as within a sequence of electronic forms. If there are more pairsto be processed, the processing may continue at block 2206 with thereceiving form element identifying data and target form identifying dataas necessary and processing the value that may be provided inassociation with the form element identifying data. On the other hand,if no more pairs need to be processed, as determined at decision box2216, the process may be considered complete.

It will be appreciated that although the process 2200 shows thereceiving of entity-identifying data and the determining of the entityidentifier may occur at the beginning of the process, in someembodiments, this entity-identifying data may be received and/or theentity identifier determined later in the process 2200, such that theentity identifier may be available for the processing at block 2212 inview of the value received at block 2210.

It will be appreciated that there are number of different technologiesand techniques by which various processes described in thisspecification may be carried out. For example, while the above has beendescribed in terms of various scripts delivered from a network-basedpayment system 208, the recording of data and providing of form fillinginstructions may be executed within a window or sub-window provided by aweb browser running on a remote machine. In some embodiments, theseprocesses may be carried out by a toolbar that a user may download andincorporate into the functionality of a web browser or otherapplication. In some embodiments, a user may download some other type ofclient-side application within which functionality described in thisspecification is included. Such a client-side application may include atoolbar, a web plug-in, a standalone desktop application, or the like.

Such an e.g. toolbar may be capable of receiving credentialstransmitting the credentials received to a network-based payment system,recording user interaction with a form or other electronic document ordocuments within a web browser window, and receiving and executing formfilling instructions and/or form filling instruction scripts.

Although the procedures described in the above sections of thespecification were mentioned in terms of an application to checkoutautomation within an electronic commerce context, it will be appreciatedthat these same form automation processes, including processes for theuse of form filling instructions and processes to automatically recordand process values entered into electronic forms, such as to allow anynetwork-based payment system or other central data repository or datamaintenance system to store entity attribute data and/or learn thestructure of sequences of electronic form, may be applied to a widerange of endeavors.

Example Computer Systems for Carrying Out Operations

FIG. 23 shows a diagrammatic representation of machine in the exampleform of a computer system 2300 within which a set of instructions, forcausing the machine to perform any one or more of the methodologies,processes, or operations discussed herein, may be executed. In someembodiments, a computer system 2300 may be used to interact with anetwork-based commerce system 206 and/or network-based payment system208. One or more computer systems 2300 may, in some embodiments, be usedto implement a network-based commerce system 206 and/or network-basedpayment system 208.

In alternative embodiments, the machine operates as a standalone deviceor may be connected (e.g., networked) to other machines. In a networkeddeployment, the machine may operate in the capacity of a server or aremote machine in server-client network environment, or as a peermachine in a peer-to-peer (or distributed) network environment. Themachine may be a server computer, a client computer, a personal computer(PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant(PDA), a cellular telephone, a web appliance, a network router, switchor bridge, or any machine capable of executing a set of instructions(sequential or otherwise) that specify actions to be taken by thatmachine. Further, while only a single machine is illustrated, the term“machine” shall also be taken to include any collection of machines thatindividually or jointly execute a set (or multiple sets) of instructionsto perform any one or more of the methodologies discussed herein.

The example computer system 2300 includes a processor 2302 (e.g., acentral processing unit (CPU) a graphics processing unit (GPU) or both),a main memory 2304 and a static memory 2306, which communicate with eachother via a bus 2308. The computer system 2300 may further include avideo display unit 2310 (e.g., a liquid crystal display (LCD) or acathode ray tube (CRT)). The computer system 2300 also includes analphanumeric input device 2312 (e.g., a keyboard), a cursor controldevice 2314 (e.g., a mouse), a disk drive unit 2316, a signal generationdevice 2318 (e.g., a speaker) and a network interface device 2320.

The disk drive unit 2316 includes a machine-readable medium 2322 onwhich is stored one or more sets of instructions (e.g., software 2324)embodying any one or more of the methodologies or functions describedherein. The software 2324 may also reside, completely or at leastpartially, within the main memory 2304 and/or within the processor 2302during execution thereof by the computer system 2300, the main memory2304 and the processor 2302 also constituting machine-readable media.

The software 2324 may further be transmitted or received over a network2326 via the network interface device 2320.

While the machine-readable medium 2322 is shown in an example embodimentto be a single medium, the term “machine-readable medium” should betaken to include a single medium or multiple media (e.g., a centralizedor distributed database, and/or associated caches and servers) thatstore the one or more sets of instructions. The term “machine-readablemedium” shall also be taken to include any medium that is capable ofstoring, encoding or carrying a set of instructions for execution by themachine and that cause the machine to perform any one or more of themethodologies of the present invention. The term “machine-readablemedium” shall accordingly be taken to include, but not be limited to,solid-state memories, optical and magnetic media, and carrier wavesignals.

Thus, a method and system for electronic form automation has beendescribed. Although the present invention has been described withreference to specific example embodiments, it will be evident thatvarious modifications and changes may be made to these embodimentswithout departing from the broader spirit and scope of the invention.Accordingly, the specification and drawings are to be regarded in anillustrative rather than a restrictive sense.

The Abstract of the Disclosure is provided to comply with 37 C.F.R. §1.72(b), requiring an abstract that will allow the reader to quicklyascertain the nature of the technical disclosure. It is submitted withthe understanding that it will not be used to interpret or limit thescope or meaning of the claims. In addition, in the foregoing DetailedDescription, it can be seen that various features are grouped togetherin a single embodiment for the purpose of streamlining the disclosure.This method of disclosure is not to be interpreted as reflecting anintention that the claimed embodiments require more features than areexpressly recited in each claim. Rather, as the following claimsreflect, inventive subject matter lies in less than all features of asingle disclosed embodiment. Thus the following claims are herebyincorporated into the Detailed Description, with each claim standing onits own as a separate embodiment.

The invention claimed is:
 1. A system comprising: one or more processorscoupled to a first web domain; and non-transitory machine-readablestorage media having instructions stored thereon that, in response tobeing executed by the one or more processors, cause the system toperform operations comprising: receiving an entity-identifying data andform identifying data; using the form identifying data, identifying asequence of one or more target electronic forms; determining an entityidentifier based on the entity-identifying data; determining formelement identifying data within each of the one or more targetelectronic forms; selecting, for each of the determined form elementidentifying data, an entity attribute identifier from a data store,wherein the entity attribute identifier is selected based on each of thedetermined form element identifying data; retrieving, for each of theentity attribute identifier selected from the data store, an entityattribute value that corresponds to the entity identifier; accessing,for the identified sequence of one or more target electronic forms, asequence table that includes details about the sequence of the one ormore target electronic forms; generating, using the retrieved entityattribute values and the accessed sequence table, and based on the formidentifying data, form-filling instructions for causing a sequentialcombination of steps that include entry of the retrieved entityattribute values and activation of selectable buttons; and transmitting,to a remote computing device, the form-filling instructions forexecution.
 2. The system of claim 1, wherein the sequence tableidentifies, for a given one of the one or more target electronic forms,a particular sequence of a plurality of sequences to which the giventarget electronic form belongs, and identifies an order of the giventarget electronic form within the particular sequence.
 3. The system ofclaim 1, wherein the form-filling instructions are executed on theremote computing device using a plug-in application.
 4. The system ofclaim 3, wherein the entity attribute values corresponding to the entityidentifier are updatable using the plug-in application.
 5. The system ofclaim 1, wherein the entity-identifying data comprises a cookieincluding a global unique identifier (GUID) from which the entityidentifier is determined.
 6. The system of claim 5, wherein the entityidentifier corresponds to a username and password of a user account. 7.The system of claim 1, wherein each of the one or more target electronicforms includes one or more form elements corresponding to the formelement identifying data.
 8. The system of claim 1, wherein the sequenceof the one or more target electronic forms corresponds to a sequence ofcheckout webpages.
 9. The system of claim 1, wherein the operationsfurther comprise encapsulating the form-filling instructions within ascript, and wherein the script is served to the remote computing devicein response to receiving a request from the remote computing device. 10.A computer-implemented method for generating form-filling instructions,comprising: receiving an entity-identifying data and form identifyingdata; using the form identifying data, identifying a sequence of one ormore target electronic forms; determining an entity identifier based onthe entity-identifying data; determining form element identifying datawithin each of the one or more target electronic forms; selecting, foreach of the determined form element identifying data, an entityattribute identifier from a data store, wherein the entity attributeidentifier is selected based on each of the determined form elementidentifying data; retrieving, for each of the entity attributeidentifier selected from the data store, an entity attribute value thatcorresponds to the entity identifier; accessing, for the identifiedsequence of one or more target electronic forms, a sequence table thatincludes details about the sequence of the one or more target electronicforms; generating, using the retrieved entity attribute values and theaccessed sequence table, form-filling instructions for causing asequential combination of steps that include entry of the retrievedentity attribute values and activation of selectable buttons; andtransmitting the form-filling instructions for execution on a remotecomputing device.
 11. The computer-implemented method of claim 10,wherein the form-filling instructions are executed on the remotecomputing device using a plug-in application, and wherein the entityattribute values corresponding to the entity identifier are updatableusing the plug-in application.
 12. The computer-implemented method ofclaim 10, wherein each of the one or more target electronic formsincludes one or more form elements corresponding to the form elementidentifying data.
 13. The computer-implemented method of claim 10,wherein the sequential combination of steps corresponds to a sequencefor a checkout process on a merchant webpage.
 14. Thecomputer-implemented method of claim 13, wherein the checkout process onthe merchant webpage includes navigation through multiple webpages, andwherein the one or more target electronic forms correspond to at least aportion of the multiple webpages.
 15. The computer-implemented method ofclaim 10, wherein the form-filling instructions are encapsulated withina script, and wherein transmitting the form-filling instructions forexecution on the remote computing device comprises transmitting thescript.
 16. The computer-implemented method of claim 15, wherein thescript is transmitted to the remote computing device in response toreceiving a request from the remote computing device.
 17. Anon-transitory machine-readable medium having stored thereonmachine-readable instructions executable to cause a computing device toperform operations comprising: receiving an entity-identifying data andform identifying data; using the form identifying data, identifying asequence of one or more target electronic forms; determining an entityidentifier based on the entity-identifying data; determining formelement identifying data within each of the one or more targetelectronic forms; selecting, for each of the determined form elementidentifying data, an entity attribute identifier from a data store,wherein the entity attribute identifier is selected based on each of thedetermined form element identifying data; retrieving, for each of theentity attribute identifier selected from the data store, an entityattribute value that corresponds to the entity identifier; accessing,for the identified sequence of one or more target electronic forms, asequence table that includes details about the sequence of the one ormore target electronic forms; generating, using the retrieved entityattribute values and the accessed sequence table and, for the identifiedsequence of one or more target electronic forms, form-fillinginstructions for causing a sequential combination of steps that includeentry of the retrieved entity attribute values and activation ofselectable buttons; and transmitting the form-filling instructions forexecution on a remote computing device.
 18. The non-transitorymachine-readable medium of claim 17, further comprising determining thesequential combination of steps, for a given one of the one or moretarget electronic forms, including identifying a particular element tobe actuated to advance the sequential combination to a next one of theone or more target electronic forms.
 19. The non-transitorymachine-readable medium of claim 17, wherein the entity-identifying datacomprises a cookie including a global unique identifier (GUID) fromwhich the entity identifier is determined.
 20. The non-transitorymachine-readable medium of claim 17, wherein the sequence of the one ormore target electronic forms corresponds to a sequence of checkoutwebpages.